The present disclosure relates to technology for data storage management, and in particular to a technology for preserving consistency of data in a remote copy facility.
Critical data is often protected against disasters by copying it to another site. One technique in use for this purpose is known as Remote Copy.
Remote Copy is the pairing of a disk (or logical volume) with another disk for use as a backup. The original disk is known as the primary and the backup disk is known as the secondary. Whenever data is written to the primary it must also be written to the secondary, to ensure the backup stays up to date. Remote Copy may be implemented synchronously—that is, so that processing at the host is delayed until confirmation of the completion of the corresponding write at the secondary has been—or it may be implemented asynchronously.
Asynchronous Remote Copy means that the host that wrote the data to the primary is not delayed while data is copied to the secondary; as soon as the data has been written to the primary the host is notified of completion. The data is then copied to the secondary asynchronously.
One of the main challenges when implementing Asynchronous Remote Copy is maintaining consistency of the secondary disk. ‘Maintaining consistency’ means keeping the secondary data in a state that the primary data could have been in at some point during the process. The secondary data is allowed to be ‘out of date’ (i.e. a certain number of updates have not yet been applied to the secondary), but it cannot be allowed to be inconsistent.
The table below shows a sequence of events. During these events the secondary is out of date in relation to the primary, but the data it contains always matches something that the host could have read from the primary, and thus the secondary is always consistent.
ActionPrimarySecondary1. Host writes AAA to diskAAAXXXXXXXXX2. Write from step 1 completes to the hostAAAXXXXXXXXX3. Host writes BBB to diskAAABBBXXXXXX4. Remote copy sends AAA to the secondaryAAABBBAAAXXX5. Remote copy sends BBB to the secondaryAAABBBAAABBB
The table below shows a sequence of events in which the updates to the secondary are applied in the wrong order. The write issued in step 3 is a ‘dependent write’ as it is issued after the write of AAA completes. BBB can therefore only be written to the disk after AAA.
If the primary had failed after step 4, the secondary would have been left inconsistent, as the host knows that at no point did the primary contain the data XXXBBB.
ActionPrimarySecondary1. Host writes AAA to diskAAAXXXXXXXXX2. Write from step 1 completes to the hostAAAXXXXXXXXX3. Host writes BBB to diskAAABBBXXXXXX4. Remote copy sends BBB to the secondaryAAABBBXXXBBB5. Remote copy sends AAA to the secondaryAAABBBAAABBB
One approach that has been used in maintaining consistency is the use of what are known as “colours”. In this approach, sets of updates are put into groups known as ‘colours’. Before applying a colour group a snapshot of the secondary disk is taken. This snapshot is a consistent copy of the secondary data. The updates in the colour group are applied, and if nothing interrupts this process the snapshot is discarded. If something goes wrong during the update process, the snapshot is copied back to the secondary disk, restoring the disk to a consistent state.
Colours are formed at regular intervals (for example, every 5 seconds), with I/O being quiesced before colour formation begins.
The drawbacks of this approach are:                Twice as much storage space is required on the secondary for taking snapshots.        A large amount of processing time will be taken up by the snapshot function, harming system performance.        The Recovery Point Objective (RPO) of the system is relatively high (for example if colours are formed every 5 seconds, then the secondary may be up to 5 seconds out of date in relation to the primary).        A fast, efficient snapshot function is required as snapshots will be taken frequently.        
The architecture of many storage subsystems prohibits this, so a different approach must be taken.
A second approach that has been used is to assign every single write that enters the primary a unique sequence number, such that if write B arrives after write A it will have a higher sequence number.
The writes are sent to the secondary, which applies them in sequence number order. This ensures that the secondary is consistent at all times, as the writes are applied to the secondary in the exact order they were issued by the host.
The drawbacks of this approach are:                Only one write can be in progress at any given time on the secondary, as each write must complete before the write for the next sequence number can begin. This would give an unacceptable level of performance.        On multi-node systems a central server would be required to control the issuing of sequence numbers. Every single write on the primary would result in a message to the server to obtain a sequence number. This would result in a very large number of messages and high consumption of message resources, and also causes delays while waiting for a sequence number to be issued.        
It would thus be desirable to have a technological means for preserving consistency of data in a remote copy facility, with minimal additional resource use.